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REMARKS 

Reconsideration and allowance of the above-identified application are 
respectfully requested. Claims 1-16 are currently pending in the present application. 

Initially, the undersigned notes with appreciation that the previous response 
resulted in the reconsideration and withdrawal of the then outstanding rejections, 
including the rejection of the claims under 35 U.S.C. §112, second paragraph. 
However, the amendments to the claims present in the response filed on December 
10, 2008 resulted In new rejections under 35 U.S.C. §103 being presented by the 
Examiner based upon newly cited documents. Accordingly, the undersigned 
presents the following so that the Examiner has the benefit of Applicant's counsel's 
analysis of the newly cited documents in considering the patentability of the currently 
pending claims. 

According to paragraph 9 of the Office Action, claims 1-4, 6-12 and 13-16 
stand rejected as being unpatentable under 35 U.S.C. §103 over MIttal (U.S. Patent 
No. 7,035,212) in view of Beshai. The undersigned believes there may be an error 
in the claim numbering since it appears from the remainder (e.g., paragraph 10) of 
the Office Action that Claims 1-4, 6-12 and 14-16 were intended. We nevertheless 
comment as follows. 

Considering first the primary document to Mittal, in the description in columns 
1-3 relating to Figure 1A, incoming data packets from a source port 14 are allocated 
an Ingress flow ID by the source port 14. The Ingress flow ID is inserted Into a field 
In the packet headers for each of the packets In the stream. A flow Is defined as a 
packet stream with the packets In the stream having similar parameters, such as 
bandwidth or Class of Service (CoS) or other requirements. The packets are stored 
in egress memory 20 on the basis of the flow ID In the packet header. 

The ingress memory hub informs the ingress traffic manager of the packet ID 
and packet size of each packet. The ingress traffic manager sends scheduling 
information for that packet back to the ingress hub, whereby indicating when packets 
for different ingress flow IDs are to be output to a switch fabric 34. The ingress flow 
manager schedules the flows according to the ingress flow IDs and the ingress 
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memory hub causes the next packet in the ingress memory 20 to be read out. The 
ingress memory hub inserts an egress flow ID into the packet header before it is sent 
to the switch fabric. Packets are queued in an ingress queue on a per flow basis or 
on a CoS basis. The reverse procedure occurs at the egress side of the switch 
fabric, using egress memory hub, memory and traffic manager. 

Column 4 of Mittal describes Figure 2, which is a detailed diagram of the 
ingress traffic manager and ingress memory hub of Figure 1 . Therein, the packets 
are shown as comprising a payload 58 and header 56 containing the ingress flow ID. 
A number N of ingress queues 42 is provided in the ingress traffic manager 16, each 
corresponding to a respective ingress queue 46 in the memory hub 18, one per 
ingress flow ID. The ingress queues 42 each contain a field 45 tracking the total 
number of packets (in the queue) and a field 45 tracking the total length of all the 
packets In the associated ingress flow. Each ingress queue also includes an 
ordered queue 47 that identifies the length of each packet received for that particular 
ingress flow ID in packet arrival order. 

An ingress packet arriving at the ingress memory hub 18 is written into the 
ingress memory 20 according to the ingress flow ID in the packet header. The 
egress flow ID associated with the ingress flow ID is loaded into field 48 and a 
forwarding label associated with that ingress flow ID is loaded into field 50, these IDs 
having been set up at the outset in source port 14 of Figure 1 of Mittal. When a 
packet is scheduled to be output, a traffic manager controller 40 informs the memory 
hub controller 44 to read the packet for the ingress flow ID identified by the traffic 
manager controller 40. The memory hub controller 44 modifies the header for then 
outbound packet by adding the forwarding label and egress flow ID from the 
respective fields 50 and 48. 

1. Mittal Fails To Teach or Suggest Storing Only The Packet Payload in 
the Ingress Memory 

It is abundantly clear from the description in Mittal that, although the packet 
headers are used in the control and scheduling of packets, there is absolutely no 
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teaching or suggestion tin at only the packet payload, i.e., the data portions of the 
packets as per Applicant's claims, are stored in the ingress memory described by 
Mittal. Mittal had ample opportunity to make this distinction, especially since the 
division of packets into header and payload portions was acknowledged in Figure 2 
and various fields were discussed in relation to Figure 2, as also outlined above. 
The fact that Mittal did not make that distinction can only be taken by one of ordinary 
skill in the art as instead disclosing the ingress memory stores data packets per se, 
including payload and header. This is, of course, quite the opposite of Applicant's 
claims. 

This being so, it is clear that Mittal potentially suffers from the same defects 
as other prior art packet processors, where the header and payload portions are 
dealt with as a single entity. Applicant expressly sets out to avoid these defects by 
separating out the header portions from an incoming stream of packets and passing 
the data portions directly to a memory where data portions of varying sizes can be 
allocated to comparable sized memory locations whilst the header portions are 
operated on in one or more managed queues. 

The passage in Column 4, lines 31-40 referred to by the Examiner in 
connection with Mittal and claim 1, clearly states, "[t]he memory hub controller 44 
writes the packet 54 into ingress memory 20 according to the ingress flow ID in 
header 56 ..." (emphasis added). It is also clear from Figure 2 of Mittal at least that 
the packet 54 consists of the packet payload 58 and the packet header 56. There 
can be no doubt that Mittal discloses and teaches that the whole packet, i.e., payload 
and header, are stored in the ingress memory. In apposition to Mittal, Applicant's 
claim 1 requires on/y the data portions (equivalent to the payload portion in Mittal) 
being stored in independent memory locations in a first memory and storing only 
record portions (equivalent to the header in Mittal) being stored in one or more 
managed queues in a second memory. 

Accordingly, it is respectfully submitted that Mittal simply does not disclose 
this feature of Applicant's claim 1 combination. 
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2. Mittal Also Fails to Teach or Suggest That The Claimed Second 
Memory Has Fixed Size Memory Locations Equal in Size to the Size of the 
Record Portions 

Furthermore, the Official Action alleges that Mittal discloses the second 
memory having fixed size memory locations equal in size to the size of the record 
portions. For Mittal to meet this requirement, the locations for the header portions 
must be equal in size to the size of the header portions. In this regard, the Official 
Action quotes column 4, lines 5-30 of Mittal. Although this passage does refer to the 
ingress queue being "associated with" flow ID, length and CoS, and a field 43 
tracking the total number of packets, these relationships bear no relation to the size 
of the memory locations relative to the size of the packet headers. It is respectfully 
submitted that it is not possible to deduce this equality from the referenced passage 
of Mittal. 

Even further, this same passage in Mittal is alleged to disclose that the 
memory locations in the first memory are arranged in blocks having a plurality of 
different sizes and the memory locations are allocated to the data portions according 
to the size of the data portions, as required in Applicant's claim 1. As stated above, 
the mere fact that there may be an association between the queues, flow ID, length 
and CoS, and the field tracking the total number of packets, is of absolutely no 
consequence as regards the required parameters of the memory locations. To be 
more specific, there is no possibility that one of ordinary skill in the art could deduce 
from the referenced passage in Mittal that its memory locations in the memory are 
arranged in blocks of different sizes and that the memory locations are allocated to 
the data portions according to the size of the data portions. 

Instead, the closest that Mittal gets to acknowledging any different treatment 
of packets is in column 5, lines 46-49, which asserts that packets may be converted 
into cells, defined as portions of packets, at the ingress side of the switch fabric. 
Normally, one would associate "cells" with ATM-type transmission systems but there 
is no such suggestion in Mittal. The reader is left wondering as to the purpose of this 
division into cells. Regardless, there is certainly no hint in Mittal that this division (or 
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"conversion", to be exact) has anything to do with the size of the pacl<et and the 
allocation of memory locations of different sizes to the data portions according to the 
size of the data portions. A packet divided into n cells could be stored in any number 
of memory locations, all of which could be of the same size, without the possibility 
that the memory locations are of different sizes to accommodate packets of different 
sizes. Mittal is simply not explicit in this respect and does not teach or suggest this 
feature of Applicant's claim 1 combination. 

Accordingly, it is respectfully submitted that Mittal does not in fact disclose 
various features of Applicant's claim 1 combination, particularly: (1) storing on/y data 
portions in locations in a first memory; (2) storing only record portions in a second 
memory having fixed size memory locations equal in size to the size of the record 
portions; and (3) the memory locations in the first memory being (i) in blocks of 
different sizes and (ii) allocated to the data portions according to the size of the data 
portions. It is noted that the Official Action relies upon the secondary document to 
Beshai to allegedly teach the feature that the first memory is larger than the second 
memory. Although the undersigned does not necessarily agree with this 
characterization of Beshai, the point is moot since Beshai fails to remedy the 
aforedescribed deficiencies of Mittal. 

Accordingly, it is respectfully submitted that that Applicant's claim 1 
combination as it currently stands is both novel and non-obvious and is therefore 
allowable, there being no other objections or rejections of that claim. Similar 
arguments apply to the memory hub claimed in independent claim 9, which contains 
the same features as claim 1 . It further follows that the dependent claims are also 
allowable for at least the reasons set forth above with respect to the independent 
claim from which they depend. 

Claims 5 and 13 stand rejected as allegedly being unpatentable under 35 
U.S.C. §103 over Mittal in view of Beshai further in view of Radharkrishnan (U.S. 
Patent Publication No. 2004/0022094). Initially, it is not clear that Radharkrishnan is 
even presumptive prior art with respect to the present application, since its U.S. filing 
date was February 4, 2003 and Applicant's priority date is November 1 1 , 2002. 
Radharkrishnan can only be presumptive prior art with respect to the present 
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application under 35 U.S.C. §1 02(e) if the relevant material finds support in the early 
filed provisional application from which it claims priority. Since the undersigned does 
not have ready access to this material, it is respectfully requested that the Examiner 
provide a copy of the provisional application if this ground of rejection is maintained 
so that Applicant has a full and fair opportunity to evaluate whether Radharkrishnan 
is, in fact, presumptive prior art. 

Regardless, since Radharkrishnan does not remedy the afore-described 
deficiencies of Mittal, it is respectfully submitted that no combination of Mittal, Beshai 
and Radharkrishnan could have motivated one of ordinary skill in the art to have 
arrived at Applicant's claim 5 and 13 combinations. 

All of the objections and rejections raised in the Official Action having been 
addressed, it is respectfully submitted that this application is in condition for 
allowance and a Notice to that effect is earnestly solicited. Should the Examiner 
have any questions regarding this response or the application in general, he is 
invited to contact the undersigned at (540) 361-1863. 

Respectfully submitted, 
POTOMAC PATENT GROUP PLLC 

By: /stevenmdubois/ 

Steven M. duBois 
Registration No. 35,023 

Date: Julv 20. 2009 
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